RooJSolutions

App Builder - Vala

2015-03-17 00:00:00

Article originally from rooJSolutions blog

As we are not so crazy busy this month, I finally get time to write about one the key tools that we developed to enhance our development process.

Back in 2010, We built a desktop application called app.Builder.js, written in seed (webkit+gnome). It's main purpose was to enable the rapid development of RooJS applications (a fork of ExtJS). It worked wonders over the years, enabling us to build and prototype applications quickly, and continually improve on them.

While it worked well, due to the nature of Javascript bindings into C, the occasional code problem would cause a complete crash. As most of the code is dependant on the javascript bindings, and gir files that define them. It also became a little troublesome to maintain, extend as it was dependent on the availability of gir bindings for new widgets.

Around mid 2014, It was decided to port the code from Javascript to Vala. Being a relative new-commer to Vala, we first tried porting our Gitlive application, which monitors the filesystem for changes and instantly commit's and pushes all changes. This relatively small project gave us the skills set ready to rebuild application builder in vala.

The Roo Bootstrap library.

2014-05-12 00:00:00

Article originally from rooJSolutions blog

A little update on our latest little mini project. Wrapping the Twitter Bootstrap library into RooJS Objects, and creating a manageable method to develop Bootstrap applications without the JQuery spaghetti.

Javascript Templating, AngularJS and Roo.XTemplate

2012-04-09 00:00:00

Article originally from rooJSolutions blog
Ok, as I said earlier, a nice Easter break, meant I could get back to coding for fun. The other issue I had to deal with over the weekend was how to do the templating for the Javascript application.

Having written a template engine for PHP, I can pretty much say that not using a template engine (which automatically escapes output) is essential for outputing HTML. It makes everything more maintainable, and reduces the risks that as a error prone human being, you are likely to open your application up to exploits.

Since most of the display logic on my applications is moving away from PHP generating HTML to PHP generating JSON, and the Javascript UI rendering this data and displaying it to the user. There has been one area I've slacked off on, that being sorting out a solution for using this JSON data from the PHP backend and rendering a elegant front end in HTML to show the end user.

Obviously this is not going to be indexed via google (Somehow JSON / Javascript interfaces are not very google friendly). But for applications that require authentication this not only helps scale the application under load, but also make it far easier to maintain.

My first effort to solve this issue was based on the original Template code in Roo (Roo.Template) however initially I decided to do the implementation in PHP. The concept was to take a group of 'HTML' template files, and use the PHP to convert those files into 'Javascript functions'. so calling the generated javascript function with 'data' as the argument, it would return the HTML to be rendered.

This basic implementation supported things like conditional inclusion, embedding Javascript, nested functions, looping and much more. It was however horribly crude and rather fragile if the template syntax was invalid. I used this for a few files relating to the ticket rendering in web.mtrack, however, I was never really happy with the solution.

Read on for my opinion / review of Anjular and the introduction to the updated Roo.XTemplate

Roo.XComponent introduction

2012-04-08 00:00:00

Article originally from rooJSolutions blog
http://www.roojs.com/roojs1/docs/symbols/Roo.XComponent.html

With a nice long Easter holiday, I finally got a chance to hack on some of those todo items that I'd been putting off for quite a while. One of the core mini tasks was to enable mtrack information inside of my main email/accounting do everything platform.

The Pman codebase, as I've mentioned before forms the core of pretty much all applications I work on now, mostly intranet or extranet focused web applications, that work like desktop applications. All of these applications are built up of various componenents, for example the Accouting module has Components like general ledger, managing invoices, timesheet and tracking editing and a pricing management component.

The whole premise of the Pman project codebase on the Javascript side, is to register all the components sometime after the page is loaded, then after the user has logged in, or authentication has been checked, it will create and render all these components in sequence, appending them to the container panels.

In the case of the Accounting module, there is a default top level module called 'Pman', which the Accounting 'Tab' is added to, then all the sub components are added to that. This whole design was done a couple of years ago, and has been working very well, it's reliable and adding extra componenets, is just a mater creating a file then saying what the parent is and in what sequence it will appear.

Read on to find out how this all works...